chromebookのCrostini(Debian)で動かしてるVscodeがいつの間にか日本語入力できなくなっていた。
Version1.106までバージョンダウンすると動くのは確認できたのでしばらくそれでほっといたのだが、間違って(間違ってはない)apt upgradeしてしまい最新版が入ってしまった。
その度にVersion1.106を入れ直すのもダルいのでいい加減なんか解決策がないものかとWEBを探ってもあまりかんばしくない。
よくわからないので結局Version1.106を続けることにしていた。
chromebookのCrostini(Debian)で動かしてるFirefoxがすぐにクラッシュするようになった。
症状としては、ちょっと描画負荷がかかるようなことをすると、サイトに関わらずFirefox内の表示更新などで落ちる感じだった。
上記のとおりなのでWEBサイトとの相性ではないのだろうと疑っていたが、クラッシュレポート何かを見てあれこれと調べているとWayland関連で通信が遮断されているらしいことがわかった。
Waylandは最近のものらしく、X11からの過渡期にあるらしい。
しらん。興味ない。使えれば何だっていいのに。
FirefoxはMOZ_ENABLE_WAYLAND=0とオプション？を吐けて起動すると従来通りのX11で起動するらしいとわかったので、試してみた所、クラッシュは収まった。
CrostiniがX11を使用し続けており、まだwayland対応が完全ではないため、グラフィック関連の通信に失敗する……ということらしい。よくわからん。
Vscodeで日本語が入力できないことを調べている間にも、waylandという言葉が登場していたことを思い出した。
IMEのコマンドが上手く言ってないだの何だのと、VscodeはElectronとかいう「WEB技術をGUIアプリに落とし込むための技術」を使って実装されているとのこと。
このElectronがwaylandに倒していて、x11を使っているCrostiniとの間で通信に失敗するとかなんとか。
しらん。マジで興味ない。ただ使えればいいのに、なんで邪魔するんだ
Crostiniの日本語入力は、chromeOSいくらかのバージョンで、ChromeOS IME on Crostiniという機能が搭載されたことで、Crostini内に独自にfcitxなどのIMEをインストールする必要がなくなった。
これとの相性が良くなかったとのことだろうか。
もう一度fcitxをインストールして前の状態に戻すなんて冗談じゃないのでやりたくない。
前述の通りFirefoxで障害を回避することができたので、vscodeも似たような感じで対応できるのではないかと思いいたり、vscodeをX11として起動する？方法がないか調べてみた。
--ozone-platform=x11というオプション？を吐けて起動するとX11で起動できるらしいことがわかったので試してみたところ、IMEが使えるようになり、日本語の入力ができるようになった。
何らかのそうした情報がWEBにあるかと期待して調べていたが、WEBにはあまり情報がなかった。
いや、個別の細かい手法(例えばFirefoxをwayland使わずに起動する方法など)は出てくるのだが、発生している問題から解決策を探ろうとしても同様の症状の人が見当たらない。
そんなことある？？？？
結局、Firefoxの件にせよ、Vscodeの件にせよ、調べるときの突破口は、Geminiに聞くでした。
チャット形式でやれるので、WEBで調べているときの……
さあ有用なものがあるならもっていけ、何が必要かは俺は知らんとふんぞり返っている書物の山をせっせと探す感じ
ではなく、有識者に相談しているような感じで、小さな手がかりから小さな突破口がテンポよく開けていく。
騙されるかどうかは、図書を読んでいても発生することなのですが……
図書の場合はこの本なんか怪しいなみたいな感覚が得られたりするところがあるので、一部回避できる。この差は結構大きいですよね。
とはいえ、ちょっと前まではWEB検索は問題解決の突破力だったのですが、もはや置き換えられようとしている感じがします。
AIに質問をすると一瞬の思考の最中にWEBサイトのアイコンのようなものが動くので、結局はWEB情報を頼りにしているのだろうとは思うのですが、知識量もそうなのかも知れないけど、知識へのインターフェイスの進歩を感じます。
です。
私があまりにも焼き菓子好きフィナンシェ好きフィナンシェ好き言うものだから、嫁さんがフィナンシェを焼いてくれました。
毎年何か作ってくれるのですが、毎年店で売ってるようなのが出てくるので凄いです。
今年のフィナンシェもうまうまで、一気に全部食べてしまいそうなので自戒しています。
小説を書いて組版する前にする作業、というと推敲が浮かぶばかりですが……
推敲って文章をより良くするとか、ブラッシュアップするための作業であって、組版に適した形式に修正することは含んでいないように思っています。
ではその組版に適した形式に修正することは何という作業なんでしょう。それも推敲の内？
そもそも組版に適した形式に修正することってのが何なのかという話ですが……
禁則処理って、よく聞くんですが、まあ平たく言うと、行頭行末に来てほしくない文字をなんとかする処理ですよね。
大まかに言うと、追い出しと追い込みがあって、何れにしても1行の見た目が変わります。
追い出し:1行の規定文字数に満たない形で次行に追い出されるので、追い出した側の行は文字が少ない形で行を終え、結果として字間が広がるか行末に余計な空白ができる。追い込み:1行の規定文字数を超える形で1行に収めるので、込んだ行は文字が多い形で行を終えるので、結果として字間が縮まるか行末にぶら下げが発生する。ぶら下げ:行頭に来てほしくない文字を追い込むとき、1行の長さを延長して当該文字を下につける。ルールというルールはないのですが、基本的にこうなるので、禁則処理が発生するとその行が目立ちます。
目立たせる意識がなくても、その行だけ文字が詰まっていたり、広がっていたり、長かったりする。
本来、禁則処理は組版上の禁則な状態を殺すための機能ですが、それを更に殺したい理由は3点あります。
組版作業あるいは禁則処理という言葉の実際の内容が、人や場合によって異なるから原稿に何文字✕何行で何ページと言った規定がある場合に、この禁則処理によって思った通りの行数・ページ数にならないことがあります。前述の通り、1行増やしたり、1行に収めたりする事があるからです。行が増減するとどうなるかと言うと、ページ数、あるいはページまたぎのタイミングがズレます。
そしてそのタイミングのズレが合計ページ数や見た目に大きく影響します。
例えば、大段落(章といってもよい)をページの頭にくるようにし、同時にその章区切りの直前をギリギリまで使うために文字を書いていたのに、突然1行増やされたり減らされると、巨大な空白ができたりします。これの見立てがしづらくなる。また、それによって想定していたページが増減したりもする。
大段落2ことかしか無くて数ページの原稿であれば大したズレではないんですが、本一冊とかになると大変なズレになります。
例えば合同誌に寄稿する原稿に何文字✕何行で何ページと言った規定がある場合であっても、それをそのまま受け取って提出すると、ぶら下がりが設定されていたりいなかったりで自分で想定していた紙面と変わっていることがある。
(そしてそれは多くの場合、本ができて頒布が終わり、自分の手元にくるまでわからない)
また、組版でのページの要件をもっと細かく教えてくださいとか禁則処理って何しようとしてますか？とかって聞くのは、合同誌次第ではあるんですが、オーバースペックなやり取りになりがちで、空気読みが必要になってそれはそれで面倒くさいんです。
あんまり変なこと聞くと、そうやれって言ってるみたいに思われそうなところも怖い。
組版には確定したルールなんてものはないので、人によって異なります。その処理がしかしページ数にまで影響する可能性がある。……触れたくなくないですか？
禁則が含まれない原稿を作れば、そうしたリスクは大幅に低減されます。
禁則処理が発生するリスクがない原稿というのは、方眼に組まれた原稿とほとんど区別がつかなくなるはずです
横書きにおいては、等幅フォント使用が前提。
上記の通り、1行の文字配置の密度が変わったりするので、字間が変わるような文字は使いたくありません。1行n文字、という前提も崩れますしね。
1行n文字が崩れると禁則の発生も想定できないので、上記のレイアウト崩れのリスクが跳ね上がります。
方眼に組むことは、組版の業界では児戯のように言われがちで、何となくみんな避けている印象があります。理由はよくわかりませんが。
個人的には、字同士の間が多少空いたり詰まったりして見えるのよりも、隣の行と比べて字の並びがガタガタな方が気になってしまうので、
プロポーショナルフォントのほうが美しく読みやすいというタイポグラフィ界隈の言が、正直わかりません。
1行しか無いようなレイアウトロゴとかならわかるのですが。
ところが、禁則を殺し特例が発生しないように書き上げられた原稿が紙面になったとき、それは方眼になるというのはなかなかの皮肉だと思います。
……し、やりがいがあるようにも思います。
マルチバイト文字を含まないテキストデータはasciiとBom無しutf-8を区別できない(区別できる必要もない)みたいな感じがして良いですね。中二。
禁則処理が発動するのは、組版作業を行うタイミングであり(前述の推敲とはなにかという観点で、推敲を執筆に含める場合)、既に執筆が終わっていて原稿を提出した後なので、そのタイミングで見た目があまりにも崩れるときには、執筆のフェイズに戻ってどうにかする必要があります。
組版作業は執筆の後に行うというのが直観的なんですが、これをそのまま認める場合、組版作業と執筆が密結合になってしまう。
またこれは多くの場合、段落内の字数調整が作業になります。そして字数調整には表現の変更を伴う。なので、この作業は推敲といえば推敲なのですが、別に文章そのものをより良くするためにやっているわけではない。
実際の場合は、MicrosoftWordや一太郎といった小説執筆用のワープロアプリケーションなどで書くので、これらは確かに同時に進行しがちではあるのですが……
例えば何百ページもの文章をwordや一太郎で書くのは、正直身軽な作業とは思えませんでした。アプリは重い、Windowsでしか作業できない、諸々。
なので、どうにか軽いテキストエディターで、例えば携帯電話やandroidタブレットも行き来しながら書きたい（家で書けばよいのでは？）
そうなると組版結果を確認しながら書けるWYSIWYGな環境はできるだけ避けたくなるんですよね（絶対Windowsで書けばよいのでは？）
あと.xlsxとか.jtdはバイナリデータなので、git管理にも向いていない(しなくてよいのでは？)
Windowsでwordで書いたって、最終的には上記の「人によって異なる」は回避できません。
テンプレートを用意してくれても、提出後に組版作業で仕方なく変更される可能性なんて普通にありますからね（それは作業上仕方ない変更）。
多くの場合、組版作業に入ったら執筆には戻りたくない。
推敲に戻るにせよ、組版作業に本格的に突入する前にしたい。
上記をまとめると禁則殺しを組版前に済ませたいという結論になります。
禁則は、原理的な話に立ち返るのであれば、禁則処理をするのではなくて、発生しない原稿にするのが正しい。
世界は禁則処理に甘えすぎだ（流石に言葉が強すぎる）。
なので、禁則処理が発生しそうな箇所を、組版前にすべて殺しておくというフェイズが必要になります。
そしてこれは推敲に入るのか？という疑問があります。前述の通り文章を良くするための作業ではないからです。ただの組版の都合です。
そうするとこのフェイズをなんと呼ぶのかという疑問が湧くのですが……まあ別に名前なんて組版でも推敲でも無いのなら他の何でもいいです。
禁則を殺したいのだが、禁則の発生を機会的に検知するためのツールはどうやら存在しないらしい(あるのかもしれんけど調べた限り出てこなかった)。
インデザにはH&J(ハイフネーションとジャスティフィケーション)違反を視覚的に表示する機能はあるようですが、そのためだけにインデザとか使いたくない。
でもさぁ、禁則処理を実施してるアプリケーションは山のようにあるんだから、それの検出方法自体は既に一般的に知られた手法があるんじゃないの？
と思うんですが、その手法だけを切り出したツール的なものは世にあまりないようです。なんでだろうか。やっぱり描写時に動的にやってるだけだからなんだろうか。
インデザのH&J違反表示も表示をしてくれるだけで、列挙したりしてくれるわけではないみたいだし。
では自前でプログラミングでもして作ればよかろうって話になる。
1行にn文字があるとわかっていれば一定文字数周期で文字種をチェックして禁止文字なら通知するみたいにすれば良さそうなものですが……
縦書きのとき、例えば縦中横が入ってきたら、2文字で1文字の高さしか消費しないので、字数がズレます。
そんな感じで、字数カウントでチェックするには結構注意する要件があるようで、けっこう大変です。
私の場合は｜基底文字《ルビ文字》みたいなタグで原稿を書くので、こうした場合には基底文字分しか文字数を消費しない、などのいろんな制約があり、チェックは面倒くさい。
こんな書き方をしている人間でないと、この文字数計算はしないでしょうし、厳密にやるのならこうしたタグをエスケープするための方法も考えなきゃいけない(そこまでしたくない)。
禁則を殺すためのツールというのは結局のところ極めてパーソナルなものになりそう、というのがわかりました。
なので、これは、自分で作るしか無いし、自分で作る価値がありそうに見えました。
……ので作ろうと思います。
ちまちまとブラッシュアップ中です。
※これは横書き日本語小説という自分の用途にしかマッチさせる気がありません。
出身は北海道なんですが、東京の寒さは堪えるというか、なんだろ……
寒さそのものの存在を地域全体が許容していない
みたいなところないですかね。
うまくいえないですが。
寒さとの付き合い方が下手というか、あまり賢くない方法でねじ伏せようとしてると言うか。
寒さに耐える家を作るのではなくて、暖房たけばよかろうみたいな。
電車の中暑すぎるんですよ。
外が寒いからって外の気温に合わせたアウター着てくると
地下とか電車の中で蒸し殺される。
加減しろって言うんだよ。
夏もおんなじで、外が暑すぎると電車の中が寒すぎる。
まぁぁ、どっちがマシかと言うと、電車の中が寒すぎるほうがマシなんですよね。
汗を書いて着ているものに影響が出るとかではないから。
(外で汗を書くのはわかるし、汗をかく前提の服を着ているのでなんとかなる)
冬汗かくのはマジで救いがない。
アウターに強烈な匂いがつく。
冬物みたいな分厚い奴に匂いがつくとクリーニング代もかさむし
クリーニングしても取れなかったりする。
なんてのをみんな認識してきているのか、
最近アウターの商品説明時のパラメーターに透湿性とか言うのを見るようになってきました。
夏に汗の湿気を逃がす性能や雨具の性能として見かけていたものですが、
最近は冬のアウターにも見かけるようになってきました。
やっぱりみんな温度差で死んでるんじゃん（要出典）
安くて暖かいアウターとして愛用してたユニクロのウルトラウォームダウンですが、
透湿が微妙らしくて、外ではいいんですけど液について電車に乗ったりした瞬間に滅茶苦茶蒸れる。
暖かいのはいいのに、社会全体が寒さを力でねじ伏せようとしている感じにアンマッチになってる感じ。
都会向きの商品ではないのかも知れない。
今はアウトドアとかスポーツとか作業着みたいな領域の透湿性と断熱性を兼ね備えた商品を選ばないとな
(後は私自身に外での寒さはある程度我慢する根性が必要か)
と思ってるところです。
そういえば雪山にヒートテックを着ていくなみたいな話も前に見た気がします。
ユニクロのもっている寒暖制御テクノロジーは湿気に弱いのかも知れませんね。
透湿性のパラメーターを見ようとすると、雨具のほうが明確だったりします。
雨具は耐水圧とかいうパラメーターが登場しますが、防寒具として使う場合には無用そうです。
透湿と断熱は極言すると空気を通す通さないに関わるので当然相反するものなのでバランスを見る必要がありそうですが
先の通り、都市部では透湿を重視する必要を感じています。
透湿防寒、みたいなやつ、防寒具よりも雨具(レインスーツ)として扱われてる傾向があるっぽいです。
今季新しいのを買い直すつもりはないんですが、次選ぶときは「雨具」カテゴリを見るのを忘れないようにしようと思います。
このサイトの大半はほぼただのMarkdownで書います。
(Pandocでhtmlに変換してgitlabにpushし、Gitlab-pagesへデプロイされるという感じ)
小説作品へのリンクを固めたindexページにはTableタグがどんと置いてあるだけ、なんですが
そのテーブルの各列の幅の扱いに困っていました。
Markdownには
ので、列幅を指定するためにPandocでhtmlに変換した後いちいちhtmlを修正していました。
とはいえだんだん面倒くさくなってきたのでなんとかcssを当てるためのclassを流し込む方法はないものかと思い、
「Markdownで要素にclassを当てる方法」
などでWEBを検索していました。
Pandocの場合には:によるスタイルの指定が効くらしいと知っていろいろ試したのですが、
「Tableの列」に当てる方法がうまく見つからない。
疑似要素のnth-childを使う方法を見つけるがこれも上手く行かない。
htmlとMarkdownからのアプローチでは無理なのか？と思い、pandoc側での何らかの機能がないかと探ると……
「Markdown解析オプションで列幅を計算する機能をマイナス-を付与する」
という方法が見つかったので試してみるも機能しない。
これはお手上げか、と思っていたところ最後に
「pandocのMarkdown>html変換では、tableの記載のヘッダー下の区切り線（|—|—|）のハイフンの数で幅を相対的に決められる」
という方法を見つけたので実施してみた所、これが機能した。
これにより解決したのだが……
「テーブル記述内の-の並ぶ数で幅を決める」……？
そんな
「幅を全角スペースの数で調整するなどという古代のhtmlホームページ作りの悪手みたいなの」
が機能として取り入れられているなんて……
と衝撃を受けてしまいました。
家ではエレコムのトラックボールのHugeを愛用しているのですが
このトラックボールはボールの支持に人工ルビーの突起を使っています。
少し前にこの人工ルビーの突起分部をベアリングに置き換えた後続機「Huge
plus」が発売されたので
買い足してしまいました。
たかい。
無印のhugeが発売から結構時間がたっているとはいえ6000円くらいで買えるのに
という差で、価格差が3倍超えてくる(今日時点での平均的な価格が19800円とか)のは、
無印からの変更で割にあった価格かと言われると、合ってないと言わざるを得ない。
無印からの変更ではなく、商品単体としての価格については正直よくわからない。
私はあんまりハイエンドマウスとかを買う人間ではないので判断ができません。
単純に「これどっちがいいの？」と聞かれた時に、
人に勧めるのは無印のほうかなあという感じです。
いや、一旦はベアリングのことめっちゃ推すけど。
これに尽きる。いい意味で。
メッチャクチャよくボールが回る。これ触っちゃうとルビーには戻れない。
Plusの方で高感度高速に設定すると、
マルチディスプレイの端から端まで一瞬で飛べる様な快感がある一方で、
指を離さずにコントロールすれば1文字単位も普通に狙える。
デカ玉トラックボールの快感は、
重たいボールを「ごろごろー」って回してマウスカーソルを飛ばして目的の辺りで指をかけてまた止めるペイロード感にある(諸説あり)。
この重たいボールが軽快に回っている感じというだけでもHuge Plusの存在意義を語れる。
デカ玉で有名なのはケンジントンだけど、ボールの大きさ以外にあまり魅力を感じないのでパス。
職場で使いたい気もするけど、家と職場におけるほどの価格ではないな……。
さっさと完成させてほとんど手入れをしなくてもいいようにしたいのだが、なかなか落ち着かない。
思う所あり一旦awkで実装し直したんですが、
更にawkらしく
/パターン/ {処理}みたいな書き方に直そうかなと思ったんですよ。
日本語文章を取り扱うプログラムなので、
行単位の処理っていうのは理にかなっていると思ってawkを引っ張り出したわけなんで、
各行ごとに、例えばルビのパターンが含まれていたらという感じで処理するのは直観的だし良いかなって。
でも実際に書いてみるとこうなるんです。
/パターンA/ {パターンAを置換する処理}
/｜[^《]+《[^》]》/ { gsub(/｜([^《]+)《([^》])》/, "<ruby>\\1<rt>\\2</rt></ruby>","g", $0 )}何がいいたいかって言うと、ルビのパターンに対する正規表現マッチングを、
とわざわざ2回行うんですよね。
これって無駄じゃないですかね……？
Awkらしく有効な記述をするのなら、
例えば「パターンAが出現する行は、行の末尾に特定の文字をつける」とか
ブロックに入るためのマッチングとは異なるアプローチがメインブロック内にある場合でないと
あんまり有効にならないということになる……気がしました。
私が作ろうとしているプログラムは、合計を取ったりするわけではなくてひたすら置換を行うだけなので、
Awkのこの書き方によるパワーの恩恵をあまり受けられないということです。
私が作りたいものとは、相性が良さそうで相性が悪かった？
いや別にマイナスということはないので相性が悪いという話でもないのでしょうけれど。
とはいえ。
正規表現のマッチングコストが処理時間に大きく影響するような巨大なテキストを相手にするつもりはないですし、
Awkのこの/パターン/ {処理}という書き方を遵守することで、
そのブロックで何をやりたいのかが明確になり可読性が上がるということはあるのかなと思います。
一方で、この「僅かな可読性」を無視する場合はただメインブロックに{処理}と書けばよいわけです。
正規表現での置換を行う場合は、
ブロックに入るかどうかの判定を行わずに必ず処理させることにしても
パターンにマッチする箇所がない場合は置換処理は空振るだけで副作用にならない。
置換処理が無駄に空振る代わりに、ブロックに入るかどうかの正規表現のマッチングが減る。
/パターンA/ {パターンAの置換}
/パターンB/ {パターンBの置換}
/パターンC/ {パターンCの置換}は、別に
{パターンAの置換}
{パターンBの置換}
{パターンCの置換}と書いてしまっても影響がなく、この書き方は当然
{
パターンAの置換
パターンBの置換
パターンCの置換
}と何ら変わらない。
Awkらしい筆致など無くて、普通の手続き型の書き方と同じになる。
もっというとこの書き方がひどく可読性が悪いのかと言うと、さほどでもない。
ひたすら置換を並べているだけだから。
なんだか悲しい。
ということで、リライトするかどうかは一旦保留になりました。
同じく可搬性が高く文字列置換に特性があるプログラム言語として、
あの悪名高きperlがあるのですが……
perlって触ったことがないんですが、仕様を見てみたら、本当に文字列操作強いんですね。
あの悪名高さの所以たる「自由度の高さ」ってperlに限ったことではないような気がするし、
他に嫌われる理由があるとすると、憶えなきゃいけないメタ文字の多さ故なのかなって感じがしました。
まあ確かに覚えられそうにない。
正直正規表現での置換をつらつらと行いたい時に、
正規表現オブジェクトを作ってマッチメソッドに突っ込んで、みたいな使い方をいちいちしたくないんですよね。
ひどいとマッチするアドレスが返ってくるだけで置換処理は別に書かなきゃならない言語とかあるじゃないですか。辛いです。
プログラマ脳的にはフィット感あるのかも知れませんけど、普通の文字列処理として直観的とは思い難い。
そういう点でも確かにperlの正規表現利用は手軽になっているなと思って感心しました。
まあ今のところ使う予定はないですが……上記の通りAwkがあんまりシナジーなかったので浮気心が無いといえば嘘になります。
基本的にLinuxならどこでも使えますしね。
Nerdy Gurdy Linotte2 が手元にあるのですが、
塗装も何もしないまま組み立ててしまったので、少しだけ後悔しています。
いやリスクヘッジとして敢えて何も塗らずに組み立てたので後悔というほどではないんですが。
高い買い物なので、自分の塗装で台無しにしてしまうのが怖かった。
redditとかで聞くと、
別に塗装なんかしなくても楽器としての性能には問題はないとの回答をもらったのですが
汚れとかがつきやすくなるよとも言われました。
後、日本は湿気があるので、湿気にやられる可能性もある。
redditで
「デンマークオイルを塗るのは手軽だし耐久性も上がって良いよ」
というアドバイスをもらった。
恥ずかしながら、デンマークオイルなるものを初耳で、取り敢えず通販で買ってみた。
今ちまちまと塗っているのだけど、組み立て前の板に塗るのと違って非常に塗るのが大変。
塗る時に手持ちできる分部を確保しなければならないので、一度に前面を塗ることが出来ない。
1度塗るのにも3回くらいに分けないとダメそう。
乾燥を挟んで3回は重ね塗りをしろということなので、これはなかなか骨が折れる事になりそう。
で、頑張って塗ったところで、組み立て済みなのでアクセスできない部分があるんですよね。
楽器の内部とかって塗れない。
湿気の問題については、この塗れない分部が残ることでクリアできないかも知れない。
……でもああいう共鳴を目的に確保されている空洞って内部は塗装しないものかな。
エレキでないギターとかも中は別にツヤツヤしてないですもんね。
取り敢えず塗装を終えてから他の調整を考えます。
ブリッジの高さにも疑問があるし、弦は一度か二度切れてからセット品の不適合品を無理やり衝けているのでそのへんはクリアしたい。
コットン巻きは未だにわからん。
唸り駒はマジでわからん。
あけましておめでとうございます。
夜伽2が公開されたようで、またなにか書きたいですね。
今書いてる最中の「経産婦魔理沙は性欲を持て余した独身ふたなり霊夢と○年ぶりのガチハメSEXで少女を取り戻す」の投稿先を夜伽2へ切り替えようかなと思います。
完全新作でなくてもいいとのことなので、2作品くらい発表済みのものを投稿しても怒られないでしょう。
bashとsedでやっていたものを、bashとawkで実装し直しました。
思ったより時間がかかってしまった。
しばらく使ってみて殆ど使わない機能を削除した。
追加した大きな機能は特に無いけどちまちまとした細かい機能は追加した。
特に「中段落の明確化」は個人的に取り入れたかったものです。
地の文とセリフの塊の間に空行を1行入れるというのは、
WEBを見ていてなんとなく昔(旧東方夜伽話投稿当時からだからもう10年以上前ということか)からやっていたことなのですが
実際にスクリプト化しようとした時に改めて調べてみたら割と気にしている人が多いのだなと驚きました。
こういう感じ
結局は書き方の問題なのですが、これを原稿に手を入れずに変更できるようにしたかった。
物理空行は、消すのは楽だけど入れるのは結構面倒くさい。
WEBの記事なんかを見ると段落で字下げさえしていないんですよね。
空行で小段落を区切っているケースもある。
ただ普通のWEB記事と違って「」類で始まるセリフが多いのと、
「」で始まる分が多いのに段落が字下げされていないとガタガタした印象を受けるので
今は小段落字下げしています。
〝「〟とか〝（〟で始まる行がセリフや思考を表す行なのは自明なのですが、
これを小段落とみなすかどうかについては割れるところがあると思っています。
個人的には「」内は一つの段落だと思っているので、行頭〝「〟から始まるセリフはやはり小段落だと考えています。
本当を言うと「」の中は〝「〟ぶんをぶら下げインデントしたいのですが、
これをすると、「」内の段落での空白字下げが2文字分になってキツイので、これはいったんやめました。
「」の中をぶら下げインデントにするのは小学校の教科書くらいまではあるようですが、
個人的に文章の構造化とその可視化という点では、これが「幼稚な文体」みたいな扱いになってしまうのはなんとなく違う気がしています。
特定の小学校教科書ではこうらしい
長いセリフの中では段落区切りをしないという一般的な慣例にも正直疑問を持っていて、
セリフの中には地の文と同じレベルでの段落は発生しうると考えています。
ただ、上記の通り字下げがきつくなりすぎるので、どっちかしか選択できないなと思って
今回は「」内の段落を優先しています。
これには直接関係ないですが、私は〝」〟の直前にもわりと〝。〟を入れます。
入れるときと入れないときには語尾の雰囲気に差があると思っているので。
「小説の組版はかくあるべし。それ以外は間違い」ということを、
市販の小説書籍の版面を例にして辛辣な口調で仰る人もいるんですが、
それって国語としての公的な決まりではなく、恐らく出版社の決まりでしかないんですよね。
もちろんそれが一番普及しているからというところはあるのだと思いますが、
私は紙面のコストカットのために詰めている要素なんかも含まれていると考えています。
つまり必ずしも言語的な正しさに従って決まっているわけではないという印象です。
(そもそも言語的な正しさの中に組版仕様なんてものは含まれていない)
一番普及している形が一番読みやすいということそれ自体は認めるところですが、
それが正しいというところには疑問があります。
もちろん私は組版の専門家でもないし
日本語の専門家でもないし、
小説を書くにもただの二次創作乞食ですし、
css組版をやろうにもcss全然わからんという雑魚なので、
なにかツッコミを入れられたら「おっしゃるとおりです……」と逃げるしか無いのですが。
今回の修正はawkで実装し直したかったのもありますし、
そんなところの可塑性を確保するためでもありました。
小段落。(セリフの行も含めて)pタグで括る。中段落としてdivタグで括ることにした。
Section。
ということで一旦の到達としました。
今後また変わるかも知れません。
最新参照
最新参照
をつけるようにしてみた。
何にというわけでもないけど。
そのうちカレンダー表示とかも搭載したい気がするけど、
そこまでするような雑記でもないしな。
年ごとにページ分けるとかそれくらいか。
絵描きさんはこれができるから良いなと素直に思う。
これで再公開してまた人に見てもらえるのも良い。露出の再利用が効くって良いよね。
というわけで今年何をしたんだっけと振り返ってみるけどまあ全く思い出せない。
転職とかなんとか、諸々リアルが大変だった印象しかないので……デジタルタトゥーを自分で漁ることにする。
今年描いた絵的なもの、たったこれだけかよ。
思ったよりは寄稿してたけど、WEB公開を目的に書いたものがなくて、
締め切りドリブンに堕している。
スケッチして遊んだ以外何もやっとらん……
みんなでスタジオで合わせたが特に録音などしていない
wrigglekickは今後活躍してくれそうなので、作ってよかった。
NerdyGurdyはちまちま練習してるけど難しすぎるのと、一人だとモチベが辛い。
何もしてない。
1年の活動量としては目標としてはこの倍は欲しい。
仕事がつらかったり転職したりしてたので……というのは言い訳にすぎないなあ。
特に文字。
寄稿はたくさんしているけど基本的に短い作品ばかりなので
執筆量は極めて少ない。
「ヘルパルラスの咆哮」はまあまあの文量があるけど、
単に文量コントロールできなくて生み出されただけなのと、
それでもこれくらいの作品はもう1本くらいは書きたかった。
「DeGrad[u]ation」1本まるまる書いていたなら良かったが、
今年に入ってから書いたのは2/6だけ。
今年は何もしなかったなあという印象。
来年はちゃんとしたい。
ある日、自前のgitlab(このサイトが置いてあるサーバ)からリポジトリをクローンしようとしたら
Permission denied (publickey).
とか死ぬほどよく見るエラーになってcloneに失敗した。
エラー自体は死ぬほど見るのだが、発生する心当たりがなさすぎる。
強いて言えば数日前にこのサーバーのgitlab−eeをバージョンアップしたくらい。
その時には一緒にユーザの二段階認証をonにした。
でも直後にアクセス確認までやったからそれが原因とはちょっと考えづらい。
理由が思い当たらないし、取り敢えずgitコマンドは全部通らないっぽい。
でもサーバそのものにsshで接続はできる。
sudo -sも今まで通りできて、サーバの中を操作すること自体に半の問題もない。
ただgitコマンドだけが通らない。
結局なんだかんだで平日夜を2日分位溶かして再度使えるようになったのだが
道のりがとおすぎたので全部書く気にはならない。
結論から言えば、何故かこのサーバーのdebian上でgitユーザーがロックされていた。
端的に言えば、
journalctl -u sshでみたサーバー上のsshdログの中に、
User git not allowed because account is lockedと記されていたことで判明したのだが、
gitユーザーがロックされるケースってなんだろう。
ssh接続に失敗しまくったりしたらロックされるのだろうか
(その心当たりもないが)
取り敢えずgitユーザーに対してロック解除を行うと、
確かにgit操作が可能になった。
ここにたどり着くのに平日の夜2日分を費やしてしまってげんなりです。
ssh接続でPermission denied (publickey).が出たときの対処法はWEB上にゴロゴロ転がっているのですが
その殆どが、
の数種類で、多くはクライアント側の問題だとゆっている。
それは当然で、gitlab(hubでもいいが)での接続不調においては
SaaSの側に問題があるなんてケースのほうが少なく、彼らは多くの場合正しい。
なので、クライアント側の問題に当たるほうが多いのだろう。
ただ、私のこれはサーバーも自分で運用しているものだから、問題の範囲は単純に2倍。
まさかサーバー上でgitユーザーがロックアウトされているなんて思わんのだけど
結果としてはWEB情報にはあまり出てこない原因だった。
でもssh -vの結果を用いてGEMINIに聞いた時に、
debug1: Authentications that can continue: publickeyの箇所が問題なので、サーバー側を疑ったほうが良い
との回答をくれたお陰でたどり着けたようなものです。AIサマサマ。
知り合いの方が、鍵の突合アルゴリズムの辺りが怪しいのかも、との話もくれました。
これもWEBには転がっていない情報です。
結果として原因はそれではなかったのですが、
こうした別の観点をくれる方は有り難いものです。
AIへの質問は、私達が若い頃に経験した「検索」での問題解決を、更に代替するものなのだろうなと思います。
なんせ今の検索エンジンの返す検索結果は汚い。
玉石混淆なんてものではなく、石をコピーして石を増やすような方法で情報を拡大し
更には企業の思惑に沿って検索結果の表示順を操作している。
見る人間は極端に多いのだから、「よくある質問」と「その回答」によって埋め尽くされてしまう。
多様性のあるWEB情報というのは、WEB世界の深淵に追いやられてしまっており、
手動検索で結果を得るのは一苦労になってしまった。
昔は検索一発と幾らかのスクロールで玉石比率1:5とかだったのですが、
今は1:20とか体感そんなモンという印象です。
このように深くまで沈んで逃げてしまった情報たちへの距離を短絡するために、
AIチャットボットへの質問というものが登場したように思える。
検索大手のGoogleが、自らのWEBビジネスのために汚しまくった
謂わばGoogle検索結果世界に対して、GEMINIという潜水夫を打ち出してきた。
どことなくマッチポンプのような感じもしないでもない。
実はGiteaとかForgejoに変えて、仮想マシンの軽量化→維持費の低減を考えていたのですが
二段階認証とか、WEB公開が容易なように組み上げられているバッテリー同梱なパッケージと言うことにも
それなりに価値を感じています。
手元にあるchromebookをForgejoサーバにできないかと少しだけいじってみたのですが
そもそも起動させるだけでも面倒くさい感じがしたので
gitlab-eeは重いけど使いやすく放っているのかなみたいな感じがしました。
老人向けにスペックの割に高い価格とサポートサービスがバンドルされた
量販店のパソコンを思い出します。
なんか技術的な話ばかりが続いていてそういう日記みたいになってますが
そんなつもりもありません。ここはただの徒然日記です。
冬です。
そろそろハクキンカイロを出動させよう……と思っていたのですが、
見ると火口がまあまあ古臭くなってる。
加熱はするので問題は無いのかと思っているけど
これって寿命どんなもんなんだろうか。
ショボいアウトライナー「WriggleKick」
の開発？というほどのものでもないが、作成を続けています。
こいつ、ただのbashスクリプトなので、
リモート先のLinuxPCに
を配置して、出先のクライアントPCからssh接続すれば
オンラインのアウトラインエディタみたいな挙動にできることが判った。
(判ったと言うか、できそうだなと思ってはいたけど特に試してなかったものを、試したら上手くいった)
ssh接続で使えるオンラインアウトライナーじゃん。
こいつはいい、ということで、
一時的利用ではあるが、
gitlabサーバの一角にgitクライアントをインストールして小説用のリポジトリをcloneし、
WriggleKickできるようにした。
自前のgitlabサーバに接続できるsshクライアントから
接続してgitlabサーバ上のローカルリポジトリの小説データをwrigglekickで編集し、
編集が終わったらpushする、という運用が可能になった。
とはいえ。
分散地点で編集して管理できるようにするためにgitにしているのだから
(一人で書いている原稿しか配置していないので、バージョン管理やブランチはあまり効力を発揮していない)
git管理している限りはあまりオンラインエディットの恩恵はないような気がする。
自前のtiglabサーバは接続にパスワードでの接続は禁じており、鍵ペアを使う必要がある。
誰かのPCでサクッと接続して、みたいな感じにはなっていないので
オンラインでSS書ける、みたいな感じにはならないだろう。
メリットを敷いてあげれば、
携帯電話のtermuxからsshして編集する場合、ローカルでwrigglekickを動かすよりも早い
くらいかな……。
いちいち接続するのがめんどくさくなったらやめます。
上記の通りtermuxからgitlabサーバに接続を維持する要求が出たのですが
接続して編集なしのまま何分か放置するとtermuxが固まってしまいます。
恐らく通信なしの状態でサーバ側がクライアントを切断するんだと思いますが
その対策として
を設定しました。
上手くいってるんだかいってないんだかよくわかりません。
chromebookってのは便利なもので、
Linuxを有効にすると優秀なターミナルが同梱されており
またそのターミナルはgoogleアカウントと連動してssh接続情報などをデバイス間で共有できます。
なので
複数のchromebookを持っているとssh接続の接続情報なんかも簡単に管理できる……
と思ったら大間違いでした。
当然ですがキーの共有まではしてくれないので
googleアカウントには結局接続デバイス分の接続情報が保持され、
その共有情報をローカルに適用するため
一つのデバイス観点では無用な接続情報が降ってくるという有り様になります。
勿論、キーの名前もキーの配置先も各デバイスで全く同じように設定すれば接続情報は一つで良いのですが。
termuxにはそんな保持機能はありませんので
aliasで擬似的に接続コマンドを作ってゴリ押ししています。
前述の通り、gitlabサーバにもローカルリポジトリを配置しました。
こいつは上２つからは接続される側ですが、
今まではchromebookなりandroid形からgitlabへgit接続していれば問題なかったのですが
gitlabサーバのローカルリポジトリから、gitlabサーバ自身へのgit接続が必要になりました。
自分自身へキーを発行して自分自身へgit接続とはまあ気持ちの悪いものですが
よく考えれば自前のPCにサーバ立てて、自前でgitのローカルリポジトリ作って学習するとかと同じ状態なので
まあ普通といえば普通なんでしょうか。
localhostだからって接続が甘くなるわけでもなく、ちゃんと鍵の設定をします。
chromebookやandroidでしている.ssh/configの設定を書き加えます。
いつも思うのだけど、この.ssh/config、
「host」と「name」の関係、なんかおかしくないですかね……
これは上述のオンライン編集など仕組み化する前の
ローカル編集の時からそうなのですが……
termuxとテキストエディタとキーボードの相性の問題がある。
テキストエディタって、
行の途中にキャレットがある状態で、shift+上下カーソルを押したら、
元の行の行頭/行末と移動先の行のキャレットまでを選択範囲として拡大してくれるじゃないですか。
自分のtermuxだとこれが出来ない。
ちなみに、chromebookのターミナルだとできます。
長らくエディタの問題なのかターミナルの問題なのか判然としなかったのですが、
chromebookとandroidの両方に、microとmseditをいれて比較してみた結果
ターミナルかあるいはターミナルとキーボードの相性のようです。
termuxにmseditいれて「これで編集しやすくなるぜ」と思っていたら
termuxのmseditで上述の選択範囲の拡大ができなくてしょんぼりしました。
いけると思って期待したのに。
とはいえこの選択範囲拡大がないと割と効率が落ちるというか
単純にストレスなのでどうにかしたい。
結論から言えば、androidのtermuxの環境では、mseditの採用を見送ってmicroのままとしました。
microにはキーバインドの設定があり、
キーバインド先の機能として「SelectDown」や「SelectUp」があります。
恐らくですが、microは独自にこれらの機能を実装しており、
ターミナル側が対応していない場合にはこの機能が上下キーでの選択範囲作成を実現している、と想像します。
(mseditにはその機能がなく、termuxではこれが実現できていなかったのかなと)
というわけで公式。
この通りに設定すればいいのかと言うとそんなことはなく、
使っているキーボード(物理)なのかターミナルなのかとの相性が出る。
デフォルトでは
"ShiftUp": "SelectUp",
"ShiftDown": "SelectDown",と書いてあるとおりだが、実際にこれが期待通りに動作しないので困っているわけです。
いろいろ試したところ、効いてほしい組み合わせはなかなか機能せず、
ようやくalt+u/h/j/kは認識できていることが確認できたので、
上記のような行をまたいだ選択範囲作成の場合には
altと右側ホームポジションを中心としたショートカットを使用するよう設定しました。
編集体験だけで言えば、mseditの方がさっぱりしていて好きなのですが
android+termuxの環境ではこれのためにmicroを使い続けます。
改めてみると、小さな画面ではmseditのメニューバーやステータスバーに当たるような分は圧迫感があり
携帯電話のような小さい画面ではまだまだmicroに分がありそうにも思えました。
↑ではナチュラルにtermuxにmseditを入れたように書いてありますが、
20251015以前は恐らくrustを入れて自前ビルドをしなければ使えませんでした。
そして私はそれで上手くいかずに断念していたのですが……
20251020くらいに、間違って
editと入力してしまったところ、
当然こちらにはeditは入っていないのでcommand not found的なエラーになると思っていたのですが……
「もしかしてmseditのことでは？」みたいなエラーが返ってきた。
え？
pkg install mseditしたら普通に入るじゃないですか。
termuxのpkgリストを見に行ったら、20251015付けで登録されていました。
すごいなtermux……。
結局使うのは見送ったんですけどね。
↓でもゆったショボいアウトライナー「WriggleKick」
割と使い物になるようになってきた。
唯一不満なのは、
フォーカスモードから編集に入って編集が終わったら、
フォーカスモードではなく普通のツリーで表示されてしまうこと。
これはアプリとして起動状態を作らないという整理から
仕方ないことなのですが……。
※このアウトライナーはあくまでも
「表示や操作を一発するだけのコマンド的なもの」
なので、「直前の操作」を記憶できない。
でもまあそれ以外は大体望み通りの機能が揃ってきた。
残り必要だなと思っているのは、
ファイル出力時にノードタイトル行内のメタ情報部分を出力しないようにすること
くらいかなあ。
それに伴って、ノードタイトル行は小説の章みたいなテイになるようにしたい。
東方夜伽話に投稿していた頃は、◆とかで章区切りを明示していた。
それと同じ感じで、
ノードタイトル行は◆を先頭に付けたうえで、完了フラグとかのメタ情報を除去する
みたいにすればいいかなあ。
SSを書いて投稿するときに
出来上がった原稿というかテキストファイルを
投稿先に合わせて整形するっていう作業が結構面倒くさいと思っています。
いや今はもう殆ど投稿とかしてないんですけど
前述の、章区切りに◆をつけるとかも
実際には「章区切りの前には空行3つ、章タイトル行のあとに1行空行を挟む」
とかを手動でやっており、これが実に面倒くさい。
他にも私は独自の整形をしていて、
「」での会話のひとかたまりを段落として扱って、地の文の塊から空行一つ挟む。
というのやっています。
他人様の文章に勝手に適用すると、こう↓
同盟敬遠主義の的になっている奴だ。吾輩は彼の名を聞いて少々尻こそばゆき感じを起すと同時に、一方では少々軽侮の念も生じたのである。吾輩はまず彼がどのくらい無学であるかを試してみようと思って左の問答をして見た。
←この空行
「一体車屋と教師とはどっちがえらいだろう」
「車屋の方が強いに極っていらあな。御めえのうちの主人を見ねえ、まるで骨と皮ばかりだぜ」
「君も車屋の猫だけに大分強そうだ。車屋にいると御馳走が食えると見えるね」
「何におれなんざ、どこの国へ行ったって食い物に不自由はしねえつもりだ。御めえなんかも茶畠ばかりぐるぐる廻っていねえで、ちっと己の後へくっ付いて来て見ねえ。一と月とたたねえうちに見違えるように太れるぜ」
「追ってそう願う事にしよう。しかし家は教師の方が車屋より大きいのに住んでいるように思われる」
「箆棒め、うちなんかいくら大きくたって腹の足しになるもんか」
←この空行
彼は大に肝癪に障った様子で、寒竹をそいだような耳をしきりとぴく付かせてあららかに立ち去った。吾輩が車屋の黒と知己になったのはこれからである。
その後吾輩は度々黒と邂逅する。邂逅する毎に彼は車屋相当の気焔を吐く。先に吾輩が耳にしたという不徳事件も実は黒から聞いたのである。
これ、
という観点から言えば、空行を挟むことは章区切りに近くなってしまうんですよね。
一方で、
地の文であっても空行を挟むことで
「段落以上章未満」みたいな区切りをする表現ってあってもいいと思っていて、
それに該当させたいという思いがあります。
中学校の時とかに習った(ような記憶があるがいつだったかは憶えていない)用語で言うと、
「形式段落」と「意味段落」の違いに似ているのかも知れません。
普通の小説の組版的には、意味段落を区切る作りはしないようですが
これはあくまでも出版社のデファクトというだけなので
なにか意図があるのならやっても良いのではと思っています。
私は文章をWEBで発表することが多かったのでWEB小説の形式に親しみがあるのですが
WEB上の文章って比較的空行を多く挟むと思っています。
一方で、改行が多くなりすぎるとも思っていて
(つまり段落でさえない文章単位で改行するケース。この雑記もそう)
ここは自分なりのスタイルを持ち出しても良いポイントなのではと思っています。
まあそんなわけで、
会話の塊を一つの意味段落の塊とみなしたうえで、
その前後に空行を入れたい。
ところがこれが、
書いているときにちゃんとやっていればなんてことはないのですが、
後からやろうとすると結構面倒くさいのですよね。
殆どのルールは大概正規表現とかで一発でできるんですが、
この「会話の塊を意味段落として前後に空行を挟む」
ってのは一発でできないんです。
正確にいうと、
すでになってるところはそのままにして、なっていないところだけ対応する
というのが面倒くさい。
一方で、プログラム的に手順を踏めばできるので、
これをツール化したい。
もっというと、
例えば上のような独自ルールだけでなくて
普通の形に整形する
(変に空行とか入っている文章を全体的に整形する)
とか
章区切りの上には必ず空行を3つとかも
指定して処理できるツールにしたい。
pixiv小説であれば、
章区切りの前には空行3つではなくて
[new
page]
と入れるとか。
まだぼんやりしかなくて要件もまとまってないですが
そんなツールを作りって、
文章を楽に書きたい。
pixiv小説は、
独自タグによってルビには対応していますが
傍点(圏点)には対応していません。
使いたい人はルビとして文字数分の﹅を設定することになるのですが、
青空形式とかでいう傍点圏点指定って、
《《》》みたいに書くので、文字数を指定しないんですよ。
なので、一度《《》》形式で書いてしまうと、
囲まれている文字の文字数分の﹅に置換するのが面倒くさいので
ルビ形式に治すのが大変。
どうしても、《《どうしても》》というのなら。って書いたものを
どうしても、｜ど《﹅》｜う《﹅》｜し《﹅》｜《﹅》｜も《﹅》というのなら。
みたいに直すのはたいへんダルい。
でもここまで直せれば、
pixivはpixiv独自のルビタグへ変換してくれる機能があるので、
あとは任せられる。
ので、
これを処理するツールは過去に作りました。
今でもたまに使います。
こういう細々としたツールを作ると
自分の細々とした作業が楽になっていっていいですね。
上記の空行挿入数を指定して整形するようなツールも
そういうものにしたい。
バーチャロン合同に参加を表明しました。
最近はVtuberがゲーム配信していたり、
コアなユーザーが未だにマスターピースで遊んでいるのをやはり配信していたりと
限られた領域ではいまだに遊んでいる人もいるようです。
あくまでも限られた世界での話。
30年も経ったコンテンツで一体どれくらい人が集まる/捌けるでしょう。
せっかく新規プレイヤーがいたとしても
今やもう「昔はやったレトロゲー」に片足突っ込んでいる印象です。
仮にコンシューマ本体を持っていたとしても、プレイ環境が特殊すぎますからね。
せめて新作でも出れば……(アーマードコア6の方を見て苦い気分になる)
ていうか、とあるコラボでさえ10年近く前になってしまったのか。
東方というバケモノコンテンツの恐ろしさを痛感しますね。
4thやってたのって大学生くらいの頃だから
もう20音くらい前ですね。怖い怖い。
合同誌の方は、
小説枠で参加を予定しているのですが、
そもそも東方以外の小説を書く機会なんてほとんどなくて
「この設定ってどれくらい説明いるんだっけ」とか、
そもそも東方での小説執筆スタンスが特殊なこともあって
「そのスタンスのまま書いてしまって大丈夫なのか」とか
まるで初心者みたいな気持ちでいます。
そもそも小説枠の参加者いるのか？
小説はページを食うので、小説枠の参加者が少ないとすごく気が引ける
足突っ込んだ時期自体は東方よりも前だし、
可処分所得(当時は学生だったので)に対する注ぎ込み額の比率は
東方界隈での活動の比ではないくらいだったわけですが、
かといってリメイクを買うという気にはなれないでいます。
ハードを持っていなかったのでMARZもやっていません。
そもそもリメイクとかで過去の作品をもう一度やるということにあまり興味がないので
バーチャロンに限らず過去に体験済みの作品のリメイク作品は買ったことがないです。
(所謂無印をやったことがないものについてはこの限りではありません)
といってても寂しいばかりなので、
リメイク作品一つくらい買ってみるかと思って買った唯一の作品はロマサガ2だったのですが
やってる時こそまあまあ楽しかったのですが、
「リメイクらしさを楽しんでね！」という自我の漏れ出しがなんか辛くなっていたのを思い出します。
1週クリアまではしましたが、2周目は別に……と思って、
やはりリメイクの書い直しは良いかなってなりました。
バーチャロンについてはツインスティックの問題もありますしね。
民生品で完全に修理できない必須コントローラって存在かなりきついです。
値段も安くはないし、ほぼ専コンだし。
アーケード時代はツインスティックの修理ができる店員がいるハコでなければ
まともにプレイができないほどのコンディションだったこともよく覚えています
まあそんなわけで、
アーケードの4th以来全く触っていないバーチャロンの
小説を書こうっていうのだからけっこう大変です。
ついでにいうと
当時学生だったので、様々な書籍などを買う余裕などなく
ワンマンレスキューだのスキマティックだのクロニクルだの、
そのへんのモノを読んだことがありません。
アーケード時代の感覚で物を語ると、
もしかしたらコンシューマーなんかで更新されているものもあるかも知れなくて
戦々恐々としています。
……まあ東方のSS書くのにだって、呼んでない書籍はごまんとあるわけで
杞憂なのかも知れませんけれど。
ロボットモノ界隈ってどういう感じの話が主流なんだろう。
全然見当がつかない。
だってプレイにはそんなに必要なかったから。
前述のとおりですが、
バーチャロンは設定を追いかけるとなると、かなり労力が必要だったので
諦めていたというところが大きいです。
その設定自体は、結構綿密に世界観が作り込まれている
(の割にそれを語るメディアは少なく、販売終了しており、入手が困難だったりする)
ので、それに従って話を作るっていうのは結構しんどい感じがしています。
東方は自由だからなあ。
ただ、
今回こういう機会に当たってWEBをかなり漁っているのですが
各種ゲームの公式サイトでは歴史や設定なんかをかなり事細かに網羅しているようで
安心しました。
特にとあるの公式サイトの情報はかなりよくまとまっていて
時系列も追いやすくてとても良いです。
アーケード入り浸ってた当時こんなにまとまった資料はなかった。
とあるのファンに理解をしてもらうために頑張ったんだろうなあという感動さえあります。
OMGから4thってオラタンを挟んで結構時代が変わっていて断絶していた印象だったんですが
こうして読んでみると結構連続していて印象が変わりますね。
今改めて新鮮な気持ちで読んでいます。
が、この大量の情報を一気に読んでも、新規の人は全く入ってこないだろうなあという気もします。
仕方がないとは思いますが
この教科書のような長大な文字群(図示はほぼ無し)では、
基礎知識が判ってる人でないと入ってこないだろう……
私はありがたく(今更)読ませてもらってますが。
こんな日記をここまで読んでいる人がいれば、あの記事も読めるかな
自作のショボいアウトライナーの試験を兼ねて、
これで書いてみています。
使っていると色々と要望を感じることがあり、
自分用に自分の道具を作ることの開放感というのを味わっています。
自分が好きなように機能を変更できるのが良いですね。
こんなレベルのものでも個人開発なんて言うのでしょうか。
githubのものを見ると、SS書くための道具ばっかりです。
他にも小説を書くうえで半自動化したい事があるので
そのツールはまた作るかも知れません。
また転職する。
次で5社目。
収入を上げるなら社内評価で昇給を狙うより
転職で条件上げてったほうがいい――
という話を実感しています。
いえ、転職で大きく収入が増えるという話ではなく
本当に些細な額というか額以前の
「昇給可能な額の幅」が微増した、というだけなんですけど。
それでもそこは会社が人間に対する支払いのアソビ分部として設けているものなので
年一とかの昇給の機会が来る度に昇給される可能性が少し緩かったり、
額が微妙に多かったりと、
効果は出てくるという感覚があります。
社内で普通に毎月会社にお金を入れていても(幅はともあれ)、
やれ目標管理だやれ成果だと言われて渋られるわけですが
転職時に「今より少し上くらいか、今より少し楽そうな働きで同程度の賃金」
は割と探せば出てくるんですよね。
私の場合は特に手に職があるわけではなく
(ITを手に職というか言わないかは別として)、
「今までSESで働いてきました経歴はこんな感じです」
「（数年前からは）一応管理職もやっていました」
ということを言えば、
どこでもというわけでは全然ないですが
行く先がまったくないということはなく、
なんだかんだで転職の失敗という事態には今のところ至っていません。
大きく成功したこともないので、 転職というリスクを踏むにしては失敗なのかも知れませんが。
今回転職を考えたのは
そうした昇給可能性幅の拡大が見える会社に接触できたことと、
純粋に今の会社にいるのが辛かったからです。
それはやはり前の転職が失敗だったのでは？
そうかも。
SESって大体
で出来上がってるんですが(私は園児ニアです)
この営業と事務が余りにも機械的で、
園児ニアのことを本当にただの
ソシャゲとかの
「探索指示を出して一定期間経ったら成果を持って返ってくるユニット」
だと思っているフシがありって耐えられなくなったわけです。
所詮園児ニアに対して何を言っているんだ、かまってちゃんか？
と言われればそうなのでしょう。
SESなんてそんなもんなのも承知しています。
ただ、そういうマインドであってもよいのですが、
「上手く隠して仕事してくれないかな」
と思うわけです。
仕事なんだから本音と建前はあると思いますけど
建前さえ使えなくなったら、
それはそれで何かの終わりだと思うんですよね。
建前が邪魔で不要になるのは、
本音分部に建設的なものが含まれている場合に限ります。
その仮面の付け替えを人間力に任せるのは土台無理な話で、
だからこそ「制度」があるのだと思いますが
それもない。
(あるのは園児ニアの働き方を規定したものだけ)
そのうち作るのだと思いますが？
できる前にこっちが駄目になるなと思っての転職です。
はい、この日記は愚痴です。
弊社は
という状況で、
まあ確かにこれを見ると失敗転職だったのかなとは思うのですが
会社が良くなる傾向だったなら悪くない流れだと思っています。
実際、数字的には良くなってきているので
そこだけ見れば可能性はまだまだあるのですが……
経営陣が入れ代わり立ち代わりなのに、
「事務」が全く入れ替わってないんですよね。
※
「営業」は人がいなくなるばかりで、グループ会社から借りているレベルで
残っているのは奴隷商としてのマインドがきっちり出来てる営業だけ。
奴隷商営業は、それはそれで商魂たくましく尊敬はしますが。
この「事務」が社内で悪い社風の温床になっており、
これを誰も改善できていないというのが実情です。
会社の歴史を知っているし仕組みも知っているので隠然たる権力を持っており、
余程の大鉈を振るわない限りはここに手を入れられない。
入れ代わり立ち代わりしてる社長を含む、現地を知らない経営では
「事務」の言うことに逆らえない。
この「事務」、一人ひとりで見ると悪い人ではないんですが
組織として見たた時に、人を使う有機性を失うみたいな感じです。
悪い組織の典型。
おそらくは起業当初からの厳しい時期を
そうした方法で乗り切ってきたのだろうと思いますが、
その事実があるからって私のマインドが強固に保たれるわけでもないので。
そうした土壌がある中で
もろもろの出来事があり転職、という運びなんですが……
退職意向を伝えた後、遺留仕掛けてくるのが、社長なんですよね。
普通、
上記の通り歴史を知ってるなら社内作業で関わりの強かった事務とか、
私を売り出していた現場担当営業とかが
声をかけてくると思うのですが、
勤務の内情をよく知らない(社内の「数字」は知ってるのかも知れませんが)社長が遺留してくる。
社長がしてくるのが嫌なのではなくて、
他の人間（つまり上記の「営業」や「事務」といった社内の人間）は
やはり動かない感じなのだな、というところで……
あーいや、これはただ嫌悪感が嫌悪を呼んでいるだけかも知れませんね、
妥当な怒りではないかも。
でも、耐える意味も感じなくなったので、転職します。というとこ。
どうなるんですかね。
最初に書いた通り、
条件自体は微妙に良くなるので
収入観点でマイナスになるということはないのですが、
将来的にどうなるかはわかりません。
そもそもSESなんて職業、ある一定の年代になればまともに稼げるものではない
(一部の特異な「SESで働いている意味がわからない人がなぜかSESにいる」例を除き)
ので、
将来なんてものははなっからないのかも知れません。
SES以外への転職は考えたんですが、
まあなんとかなるだろうという甘い考えはあります。
なんとかなるだろうと思う理由は、ひとえに
SES起業で園児ニアをやっている人は、
言葉を選ばずに言えば
まともでない人が多いからです。
などで、
管理職をできる人が極端に少ない。
やりたい人もいない。
これは私の年代特有の問題かも知れません。
もしかするともう少し年代が進むと、
その変折り合いをつけて働く若者が担ってくれるのかも知れませんが……
この感じなので
今は
の状態です。
なので「競争倍率の低いまともさ」だけで収入を上げて行けるからです。
「就職・転職で無職だったことがない」のはこれのおかげだと思っています。
なんか、誠実そうに見える、とからしいですよ。
SES人事の目って節穴ですね。
現場などでマネジメントや技術を多少なりとも積んでは行きますが、
はっきり言ってこれは大きいです。
何の努力もなく(努力はしませんが我慢はします)、
「なんとなくまともそうだから」の理由だけで、生きていける実態があります。
(手に職がない、といったのはこれ。いや、実際はジリ貧なのでは？)
このクソ野郎、と罵られるものの見方ですが、
しばらくはこれで食いつなぎます。
正直、
そうした「我慢」の間に身につく技術や好転するものもあると思っているので
その間に何らかの契機を見出したいですね。
なんか資格を追加したほうがいいかな。
今更勉強なんかできるかな。
副業とかできるような器用な人間ではないしなあ。
2025/08/30追記
2024/11/08 に書いた通り、
ハルナアウトラインがいなくなってしまったので
自分でそれっぽいものを作ることにしました。
ちなみにobsidianは面倒くさくなってやめました。
ただのシーケンシャルなテキストを書き連ねるのにも向いていないし
アウトラインエディタとして使うのにもあまり向いていると思えない。
ナレッジベースをワープロとして使うなんてのが土台無駄な話だったのだ。
自作のお粗末アウトライナーもどきはgithubにおいてありますが、
大層なものではありません。テストも不十分です。
今後実際にこれでSSを書きながらブラッシュアップします。
https://github.com/y-mikou/wrigglekick
やりたいこととかなんとかはそこに書いてあるので
改めてここで書かなくてもいいのですが。
上記の粗末なアウトライナーもどきを作るにあたって
話題のAIでも使ってみようと思って
Devinというのを使ってみたのですが、
おそらく指示の仕方にテクニックが要りますね。
あんまり芳しくありませんでした。
使い放題な課金をして思い通りに作業させる技能を獲得しないと、
有効に使えなささそうですね。
これは画像生成AIとかでプロンプトが重要だったり
それを扱える人がそれで仕事ができるくらいには難しいということの証なのかもしれません。
AIエージェントが何をどう変えてプルリクエスト送ってきたのか、
きちんとdiff内容を見るか、
あるいは確認すべきテスト観点を網羅的に伝えるか
どっちかが必要なのかもしれません。
そういうのをしたくないのだが。
企業が人をひとり雇うつもりでAIエージェントを使うというのであれば安いのかもしれませんが
個人で金にもならない開発をするのにはちょっと「富豪」を感じました。
個人開発とかも
「趣味で作ったものが人のニーズにマッチしてお金になった」
というフリーソフト時代のマインドではダメで
最初からマネタイズを意識する必要があるのかもしれません。
(開発そのものが楽しい人は問題ないのでしょうけれど)
いっぺん、長期休みを取った上に使いたい放題な課金をして思い切りやってみればいいのだろうか。
そこまでして作りたい規模のものがない。
上のアウトライナーもどきだって、
プログラミングが上手にできる人にとっては
わざわざ「つくった」なんていうほどのものでもないし
AIなんか使うほどのものではないだろう。
やはり「プログラミングして作りたいものがない」が立ちはだかる。
少し脇道にそれてしまうが、
私のように
自分にとって必要だが誰も自分のニーズに合ったものを作っていない
ので自分で作る必要がある場合については
(作らねばならぬものは変わっていないが、
ニーズがあるものについては高難易度高速化が逆に可能性を増すという意味で)
AIの台頭によって相対的に辛くなるのかもしれません。
AIを使ったコーディングは能力の高い人間にしかできない
という言説はこうしたところで実感します。
正直なところ、私自身はプログラミングそのものはあまり好きではないです。
仕事で仕方なく少し触れることがあるというだけです。
世にいう園児ニアです。
ただ、
プログラミングという行為そのものと、
その時間が確実に答えに近づく(やれば成果に近づく)というのは感じていて、
悪い言い方をすると作業に逃げるという感覚が得られると思っています。
もう寝るには今日はあまりにも何もしてないので何かしたいというクソみたいなマインドのときに
とりあえず、
1機能を更に細かくした何らかの単位だけ進めてから
その悦に入った状態で自分を誤魔化して寝る。
絵でも文でも細かすぎてなんにもならんし
何の成果でもない単位しか進められない時間でも
プログラミングならわずかに成果が可視化される。
(絵よりも可視化されるというのは皮肉なものだと思う)
みたいな逃避先としての有効性を感じています。
プログラミングが好きな人に殺されそうな発言ですが。
私個人の感覚としては
人間に依頼すると2、3時間の作業を、丸一日とかかけても良いので
私が見ていない間に自動的にやってくれるAI
というのが欲しいと感じています。
AIにやらせている間に自分は絵をかけるとか、
AIにやらせている間に自分は本業のサラリーマンをやってられるとか
欲しいものを創出するのに作業を多重化したい
という思いが非常に強いです。
誰でもそうだと思いますが。
作業単位を大きく取ってうまく解釈されず手戻りする可能性はよくわかっているし
もし十分にうまくやるAIがいても効果で手が出ないだろうと理解しているので
作業は低速でもいいから安価というところが
私の重要なニーズに感じています。
今のAIサービスは時給払いなので時間をかけられると逆に高く付くので
こういうニーズにマッチしません。
自分で作るしかないのか(ループ)(無理)
こうした状況になる背景はAIが流行りの技術だから安売りされないのだと思っていました。
ところが先日おもしろいニュースを見ました。
要約
MITの調査により、調査対象となった組織の95%がAIへの投資から収益を得られていないことが判明した。
生成AI分野へは300億ドルから400億ドルという巨額の投資が行われているが、多くの企業でリターンがゼロである。
この結果は、AIへの期待が先行し過熱する市場への警鐘であり、投資家の間に不安を広げている。
AIツールの導入において、自社で一から開発する「ビルド」よりも、既存のツールを購入する「バイ」を選択した企業の方が、成功率が高いことが示唆された
ちょっと悲観的すぎるのでは？と思うところが大きいですが……。
そもそもテックではない企業にとっては
AIの存在にかかわらず、ITそのものが多くの場合採算部門ではないのだから、
AIへの投資が目に見えるリターンを生むことの方が少ない、と思っている。
なので、
これは30年前のシステム化なんて金食い虫だみたいな言説の焼き直しでしかないのだろうと感じています。
今の仕組みでは数値化・可視化されない利益が出てくることになるはず。
しかしそれはそれとして、このような状況があるのであれば、
AIサービスを安く提供するようなことはないだろうなということにも合点がいってしまいます。。
長く契約してもらうことが一瞬の高火力より価値があるような商材ではないので
私が上で言ったようなニーズを満たす課金プランは生まれないだろうなと思います。
……生まれてほしいな。
大した出来のものではないが、
一人で文を書いて
一人で表紙絵を書いて
一人でCSS組版して
本を作ったりしている人間なのですが、
だったら絵や文はAIにまかせて多重化しないのか？
と問われると結構痛いです。
それは上記での
「システムは採算部門ではない」
というのと近いのかもしれません。
私は成果物そのものを高速で自動で作って欲しいのではなくて
やりたいことを気持ちよくやれるようになるための
「道具」
が欲しくて、
その道具そのものを作ることは誰かに任せたいと思っているのだろうということです。
CSS組版だって、
ある種の管理を簡易にするために着手したことでしかなく
それ自体をやりたいなんて1ミリも思っていません。
自分が価値を感じているコンテンツの創出に注力できるように
他の価値(他のものを生み出す労力)を無視したいという
極めてわがままな発想なのかもしれません。
ちなみに、あとここに「その人の独創性」みたいな幻想を注入して
話を拡大するつもりはありません。
(私はオリジナリティとか独創性とか個性というものそれ自体を
無視こそしませんが、あまり神聖視していません。)
100%オンサイトになって無事死にました。
しかも普通に時間外が多くて、22時過ぎに終わって帰宅が翌日、みたいな生活を久々にやっています。
そんな仕事の状態でも大好きそうな題材の合同誌２つに参加させてもらって、無事寄稿も間に合いました。 なんとかなるものだなあ。
参加した合同誌の他の作品の感想とか、後日書きます。まだちょっと時間取れない。
本丸がこちらなのですが、仕事が全く波引かなくてあわや２年連続新刊落としかと思ったのですが、なんとかなりました。
なりましたったって、去年のやり残しのSSの２単元書いただけなのでほとんど何もやってないんですけど。
…と書くと少し恣意的だけど、
Copilotとの抱き合わせによりCopilot分の価格が上乗せになるということで
ということで、MS経済圏からの離脱を考えた。
今のところMSアカウントで運用してる有料サービスは
といったところで、
Ms365の中にはOnedrive1Tぶんが含まれている。
これらを別のサービスに逃しつつ、料金を安くしなければならない。
やってないので解約。
chromebookでクラウドゲーミングができると思って契約を維持していたが、
ゲームタイトルのラインナップそのものが微妙。
前述の通り、Officeアプリは切り捨てることに。
会社で使っている分は、会社のアカウントで運用するのでこの件とは切り離されるし
会社で操作を求められるExcelファイルがオンラインで満たせないのであれば会社にいう。
(Windows機があることを求められていないし与えられていない)
たまーにwordを使うこともありましたが、
今後は諦めることになります。
同人活動とかしてた履歴データのアーカイブとして利用していたため、
なにげに数十Gbyteはあった。
これの逃し先の選定には難儀したが、
pcloudという買い切りクラウドストレージがあったのでそれにしてみた。
タイミング的にセールをやっていて、２Tが割安だったので２Tに。
そこまで使わない気がするけど、一応移行先としては十分なサイズになったので移行しました。
別にMs365には関係がないのだけど、
ちょうどさくらのクラウドが話題なので、かこつけて乗り換えてみることにした。
一応料金はAzureの仮想マシンより割安。
今のこのサーバはすでにさくらのクラウドサーバに設置されたgitlabになっている。
私はインフラ知識0なので、乗り換えに関して色々手間取ったけれど、それはそれで別の機会に書こうかな。
苦労した割に、月間5000円が3000円になる程度の圧縮でした。
率としては大きいのだけど額としては…。
まあクラウドとしてAzure以外に触ってみるいい機会だったのでヨシとします。
Ms365
personal自体、MSとしてはあんまり世話をしたいサービスではなさそうなので
今後も旨味はなくなっていくのかなあという感じです。
でもCopilotと抱き合わせて使う場合には、
今後は個人ユースでVscodeからコードアシスタントとしてcopilot使うルートも出てきそうですね。
Ms365 personal、値上げしたあとでもAiクレジットに制限があるので。
これが無制限だったら維持していたかもしれない。
円安のせいで海外製品は値上げがきついですね。
Azureの代用としてさくらのクラウドを選択したのも、
国内サービスだからいくらかは海外のアオリを吸収してくれるだろうとの期待あってのことです。
パソコンディスプレイが壊れた。
入手時点で中古だったので、まあ妥当なタイミングだったかもしれない。
現在
の3台が自室で稼働しているが
元々バラバラのディスプレイをバラバラのアームで2枚使っていて
バラバラなのが気に食わなかった。
(全てノートPCなので1枚は普通に運用していた)
と、いっても強い必要がなかったので我慢したままいたのだが、
そのうち1枚が壊れてしまったのもいい機会なので
2枚揃えで買うことにした。
私はパソコンで反応速度を求められるゲームをするわけでもないし、
プロ級の色彩表示を必要とするわけでもないので、
27型で1万強の安価なディスプレイ2枚とディスプレイアームを1つ買った。
だから何だというわけではないのだが、
画面の映りが良くなって少しだけパソコン前QOLが良くなった。
残念なのは、Amazonブラックフライデーの存在を、忘れていたことだ。
仕事としてはIT業界にいるのだけど、
実際にはそんなに開発とかやることはなくって、もっぱらExcelとにらめっこしている。
社内的には〝Javaの人〟ということに鳴っているが、別にJavaが特別上手に実装できるわけでもない。
そもそも実装は苦手だ。
画面の設計書を書くこともあるが、
基本設計/画面レイアウトくらいで終わってしまい、その次には試験仕様書を書いたりすることが多くて
web画面というのがどのように動いているのか今ひとつわからない。
とかく、実際に要求に直面しなければどうにも勉強ができない性分で、
よくこの界隈で言われている「なんでもいいから作ってみろ」というのがどうにも億劫だしやる気も出ない。
勉強になるだろう、とおもって「東方夜伽合同2」の組版担当を買って出てcss組版というものをやってみたが、
htmlをちょくで書くような作業が殆どになり、モダンなwebのメカニズムなどを知るには至らなかった。
html+css自体は勉強できたのでその点は良かったと思っているが。
なんか興味を引くフロント技術はないものかとウロウロしていて
興味が湧いたのは「elm」という言語なんですが
あんまり資料がない。
elmの記事を探すと、elm自体の情報よりも
〝elmなんかやるくらいならもっと別のがあるだろ〟
という言説の方が多く目に付くありさま。
私がelmが気になっている理由は
という、プログラム界隈でいうとあまりプラスに捉えてもらえなさそうな要素ばかり。
まあそのゆっくりさをいいことにゆっくり勉強していけば良いのだが……
というところで少し前の話に戻る。
勉強するための「必要」が眼の前に転がっていない。
このwebサイトをelmで作るという目標は建てられそうなものだが
実際にやろうとしてみたときに障害になるのは、
「小説というプレーンテキストを公開する」
という目的の方にある。
既存の小説データリソースをelm/htmlパッケージでゴリゴリに加工するのはアホらしいし、
それ以外のページをelmにしようとしても作品リストくらいしかない。
今はmarkdownファイルからpandocでhtmlを吐き出す定型化を終えているし
小説データに関してはtextファイルをhtmlに加工するスクリプトを自作してあるので、
実際にはあまり困っていない。
別に静的サイトジェネレータを求めるほどの更新頻度もなく、
つまりelmで置換する要求がそもそもない。
サブスクリプションなどを使って非elmなjavascriptとの通信、などやると
学習曲線の勾配が急にきつくなる上に情報ノイズが上がりすぎるのでやりたくない。
副作用を殺しにかかっているので自ソース以外からの要素を極力排除しているのだろう、
そのせいで、
「既存のデータを上手いこと摘んで自身の中に取り込む」
というような使い方は難しそうに見える。
勉強をしたいというよりは、
この言語を使えるようになってみたいというところなのだが、
このざまなのではかどらない。
まあ、そんなこと言ってないでやれらなきゃ学びは進まないってことなのかしら。
新規作品
「経産婦魔理沙は性欲を持て余した独身ふたなり霊夢と○年ぶりのガチハメSEXで少女を取り戻す②」
を登録しました。
このくらいの長さのSSを書くのに、1ヶ月以上かかってしまうのはなんだかなあ。
生活リズムの中にSS執筆が組み込まれていないというか、はじき出されてしまったというか。
昔は〝食う寝る仕事するSS書く〟くらいだったのだけど、今は〝SS書く〟が消えてしまっている。
自分のパソコン部屋が2階にあって妻が1階にいるので、なんか部屋に引きこもってSS書いてるのが、彼女を放っておいているみたいで後ろめたい。
なので、茶の間にいて遊べるテレビゲームなどで時間を過ごすことが増えてしまっている。
全く話しかけられない他人しかいないような場所(例えば喫茶店のような)であれば人がいてもかけるのだけど
話しかけられると途端に書けなく鳴ってしまうものだから、茶の間でSSをかくこともできない。
ゲームやるのもこんなしょうもないスケベSS書くのも、大して胸を張って言えることではないんだけど。
とはいえ文章を書いているときが一番楽しいというか気分が落ち着くので
なんとか生活の中に収め直したい。
SSを書くためのツールとして環境はだいたい整ったのだけど、
やはり、勝手にインデントされてしまうのがキツい。
それ以外はまあまあ優秀で、特にタイプライタースクロールが出来るのが良い。
今少し慣れの期間が必要。
アウトラインエディタとしてハルナアウトラインというのを浸かっていたのだけど
作者さんになにかあったのかgooglePlayから消えていた。
この作者さんの他のアプリも全部消えていたので、作者さんがもう辞めてしまったのかもしれない。
家でしか文章を書かなかいのなら豊かなWindowsのテキストエディタから選べば良いのだが
手持ちの執筆環境はchromebookとandroid携帯なので、AndroidアプリかwebアプリかあるいはLinuxアプリが都合よい。
なので、vscodeなどは便利なことはわかっているけど使えない。
※Androidアプリにもvscodeはあるのだが、拡張機能など全く使えないので役に立たない。
できれば春なアウトラインに復活してほしいが、
WindowsのフリーソフトのようにOSが後方互換を気にしてくれるわけでもないし
そうした背景のもとexeさえあれば使い続けられるというわけでもない携帯アプリでは避けられないことなのだろうなあ。
幸い(アプリ選定時に考慮に入れてはいたが)ハルナアウトラインが扱うファイル形式は、
拡張子こそ.holとなっているがその中身はただの特殊な階層構造テキストであり、
アプリが使えなくなったとしても救出は容易なので、
なにか次のアプリを探すしかないだろうなあ。
ということで、白羽の矢が立ったのがObsidian。
昔からnotionの代替品だとか、onenoteよりいいだとか、色々言われているのを目にしていたので気にはしていたのだけれど
この状況になったので重い腰を上げて使えるかどうか試してみることにした。
結局はただのmarkdownエディタのバケモノであって、アウトラインエディタではなかった。当然日本語文章を執筆するのにも向いていない。
インデントは強制だし、
アウトライン機能はアウトラインを書くことしか考慮していない。
(ハルナアウトラインのようにタイトルと本文を内包したノードという考え方ではない)
配色の変更なども自由度が高そうな割にはテーマを選ぶタイプなので思っているほど自由はない。
(一応cssをゴリゴリ編集すればなおせるのだが、テーマによっては難読化が施されていて直す気になれない)
とはいえ、
という点は満たしていて、他には選択肢がない感じ。
色々と手を入れてなんとか使えるようにしたので、しばらくはこれで言ってみることにする。
当サイトのリソース自体はgitlabに登録してあるのだけど、
編集自体はローカルでやっているし、.md→.htmlの変換とか諸々もローカルにインストールしたpandocでやってる。
今後この雑記をもっと簡単に書きたいし、ローカル煮物をおいておくのもなんとなく嫌なのと
変換作業諸々もサーバ上でやれたらなとおもっているので
そのスモールスタートとして、サイトのリソース編集環境をサーバにも作ってみた。
サーバ上のリソースはvscodeのリモート接続で直接触れるので苦痛がない……のだけど、
これだとサーバ上のhtmlを直接書き換えるのとかと対して変わんなくて、gitlab-pagesしてる意味がまるでない。
やっぱりCI/CDというやつをやらないとダメか。
gitlab-pagesのrunnerは自動デプロイの仕組みを提供しているものらしく
それは既にテンプレからコピーする形で利用しているので、
そのへんを切り口にやっていけるだろうか。
最初は、いまローカルでやっている
「mdファイルを書き終えたらpandocコマンド(を内包するシェルスクリプト)を実施して、特定のディレクトリに置く」
という作業を
「mdファイルをpushしたらpandocコマンド(を内包するシェルスクリプト)を実施して、特定のディレクトリに置く」
という形でサーバ上でできないかチャレンジしてみようと思う。
また長い戦いになりそう……
なんか懐古的な感じで、リンク集なるページを作った。
けど自バナーもないし、相互を依頼する先があるわけでもない。
片想いにせよリンク先を増やすかどうかはともかくとして、自バナーくらいは作っておこうかな。
時代は流れたもので、〝バナー〟と言われるものの形やサイズも随分変わったらしい。
多くはweb広告の形を取っているので、あまりいい印象のない形状だったりもするのだけれど、マシンスペックの向上やブロードバンドの普及からリッチなデザインが増えているようで表現力という意味では拡大したのだなと思う。
まあ広告としての拡大なんで、そういうサイズのバナーをwebサイトの看板として使うのかどうかというと、どうなんでしょうね。
新規作品「経産婦魔理沙は性欲を持て余した独身ふたなり霊夢と○年ぶりのガチハメSEXで少女を取り戻す①」を登録しました。
予定は未定ですが、全部で④くらいになるかな。
久しぶりに頭を空っぽにして書こう……と思っていたのですが、スケベSSって別に書くとき無心では書けないんですよね。
この避難所を作る前くらいからライフイベントが立て続けに発生していて以来あんまりSS書けていないので、少し書くようにしたい。
ここでやめてしまうと、もう再開しなくなってしまいそうなので、細々とでも続けることが大事かなと思い、縮退運転。
とはいえ、ライフハックしていかないと。
家のこととか、親族のこととか、会社のこととか、自分の体のこととか、一気に全部来た。
このサイトはGitlab-eeの片隅に置かれたGitlab-Pagesという機能で表示しているのですが、そのGitlab-eeのバージョンが古かったのでアップデートしようとしたところ、古すぎたのでちゃんとアップデートできず、面倒になったので新しいサーバを立てて最新のGitlab-eeをインストールして元通りの表示にしよう……
と思ったのですが、これがなかなかうまく行かなくて片手間や暇なときにだけ作業し続けること足掛けひとつきくらい掛かってしまいました。かかりすぎだろ。
古くてアップデートできなかった以外にも、旧サーバではbitnamiというアプリケーションを簡単にインストールする仕組みに組み込まれたGitlab-eeを使っていたんですが、
なんかどうせ管理するならプレーンな環境のほうがいいだろとか血迷ったことを思ったせいでサーバそのものを入れ替えることにしました。
のですが……やめておけばよかったなと少し後悔しています。
アプデ作業、あまりにも意味がわらかなくて泣きそうだった。
でもお陰でプレーンな環境に立て直せたし学びもあった。
Gitlabサーバの移行作業なんて、仕事でもやったことないよ。
そそわにも上げていたのを忘れていた。 ローカルにあるものから適当に復元して満足していたが、それだと不足だったらしい。 アップロードしたもののうち幾つかはローカルに保存できていなかったようで、元サイトから抽出、当サイトにアーカイブし直した。 古い作品というのは「そういえばこんな痛々しいものも書いていたな」と辛い気分になりますね。
今は、SSの元テキストをHtmlに変換するスクリプトを用意して、作品ができあがるごとに最終原稿としてのtxtを保存すると同時に、この最終原稿をHtmlで変換したものを作って、web資材としてはHtmlの方をアップローロしてここで表示するようにしている。
このテキストは(万一必要があれば)そのまま組版作業に投げ込めるようになっているのである程度の単一ソースを実現しているのだけれど、
それでもtxtとhtmlの二重のリソースを保持することに変わりはなくて、
なんとかならんものかと悩んでいる。
とはいえ、これ以上のことをやろうと思うと、もうwebアプリみたいな姿になりそうなので、ちょっといやだな……ただのアーカイブだし。
サイトとかではなくてリアル引っ越しです。 前の家を3年で引き払うとは思っていませんでした、10年はいるだろうと思っていたのに。 しかも駅から遠いので不便になりました。意味……。
サイトは引っ越したのではなく証明書が切れていたので更新しました。 Let’s encryptとcertbotの組み合わせ、自動更新を導入しないといい加減だるい。
自分の本ではないけど、寄稿原稿を提出するときの比較対象として久々にVivliostyleViewer基準で組版をした。 幾らかCSSに気づきがあって修正できた。littlebugの精度(CSS部分)も少しは上がってきている。 置換処理にも幾らか直したいところもあるけど、まあしばらく先になりそう。
おそらく手元にある過去作は整形・登録し終えた。 まだ作品側のCSSに問題があって思い通りの表示にできていない。
問題は多いけど、一旦「公開する」のステップは完了。 ひでえつかれる。
横向きでおっきい画面、縦画面、ちっさい横画面、で表示を変えるということをやった。 面倒くさかった。 悪い文化だと思った。
夜伽から自分の作品をスクレイピングでサルベージしたとき、シリアル#、投稿年月日時、作品名を付与して取得した。
ファイル名としてふさわしくない要素を含んだいくつかの作品名があり、適当にリネームすると同時に正しい作品名はファイルの中に取り込んでいる。
ところが、スクレイピングするときに下手をコいていて、
夜伽の表示作品ソートを指定せずにスクレイピングした結果、
シリアルナンバーの降順・昇順は、投稿日時と同行しないという状態になっている。これが元凶。
作品集ごとに新しいものが上に来るのに、シリアル値の採番は上からスクレイピングされた順なので、
作品集ごとに新しいものが若いシリアル値を振られている。 なのに「作品集」単位では古いものから指定している(URLの指定時に作品集の番号をカウントアップしながら取ったため)。
※「作品集」とは、確かweb上の表示作品が50作ことにページングされるその単位。
まだあまりデータを云々するつもりがなかった頃は全然気にしていなかったのだけど……
実際にこうして別の場所で公開しようと思ったときに、作品名をファイル名にできないため、シリアル値をファイル名にしようと思ったのが運の尽き。
一括リネームしてみると全く順番に並んでいなかったり、シリアル値の指す作品が異なったりしててんやわんやとなった。
こんなもん普通に考えれば、投稿年月日_短縮作品名(作品名から切り詰めた文字列).txtで十分なわけで、シリアル値なんかいらなかった。
(1日に複数回の投稿なんかしてなかったので、投稿日時の年月日部分で一意になるになる)
要件定義は大事だねってことを思い知った。
現在、作品内のクリンナップをしながら、ファイル名の修正もせっせと行っている。 作品名はファイル内の先頭にheaderみたいにくっつくのでいいや、となっている。
配置するSSを横書きにするようにCSSを修正した。
めでぃあくえりというものをいじってみた。
携帯の縦画面では幅いっぱいに表示して、横にすると余裕を作って真ん中に表示するように。
なんとなくそれっぽくなった。
このCSSは独自のものではなくlittlebugの同梱物なので、そっちにもCSSをpushした。
littlebugは変換後にbody以下のタグしかつくらないのを忘れてた。html〜bodyを作らないと表示が正しくならない。
もともとはもう少しリッチなサイトにしようとしてたときには、html〜bodyは共通になるのでjsで自動読み込みするようにしてたけど、今回からそれはなくなったので個別に作るようにする。
そのためのかんたんなスクリプトも用意しようとおもっている。
そういえば、githubにもpagesがあるのを思い出した。
vuepress使ってないし、md→htmlの変換は自前のpandocでやってしまっている。 netlifyを使う必要特になかった……。
vuepress使えば見た目はきれいになるんだけど、管理のコストが……いや管理っていうか、周辺技術の面倒見あたりがめんどくさい。
確かに軌道に乗ればもう手はかからないんだけど、例えば時間が相手から「久しぶりに更新するか」とかなったときに、どこをどうすればいいのか思い出すのがだるい。vuepressがレガシー化したときにも面倒が出そうだし。
過去作SSなんてコンテンツ自体がレガシーなんだし、見た目なんかきれいにするのも正直面倒……
というわけで、github-pagesに設置したこのサイトの入口……の入口をtwitterのプロフにだけ書いた。
誰もみとらんと思うけど。
さっさとSSデータのクレンジングしないとなあ。
当退避所の本題、過去作SSの登録を一部だけやってみた。
過去作データのクリンナップは超鈍足で進んでて終わってない。
夜伽からスクレイピングでサルベージしたtxtデータに対して、
「ルビや圏点の記法統一」や「空行の入れ方の統一」などを
横断的に行って整形しようとしている。
pixiv小説や他のSS投稿サイトでの再利用可能性を高めたくてやってる。
とりあえず1個だけやってみようということで、
クリンナップ済のSSを、自作のbashスクリプトlittlebugにかけた出力結果ファイルへのリンクを、トップに設置してみた。
一応リンクはできたのでヨシとしよう。
littlebugプレーンtextファイルをhtml表示可能なようにタグ付けする他、
「｜《》」形式のルビをhtmlのルビへ変換したり、
もろもろhtml表示できるように変換するスクリプト。
GitlabPagesを使って退避所を作るのはいいんだけど、GitlabPagesにするとGitlabサーバが寝ている間はサイトが死ぬ。
「現在は営業時間外です」みたいな表示をしてくれるページがほしいけどgitlabサーバが寝てる間はGitlabPagesも当然表示できないので入口も表示できない。
そういえば昔netlifyを使おうとしてたけど使えなくてやめた跡地がある。
netlifyは18禁ホスティングできなさそうだったのでやめた。
あとvuepress勉強もめんどくさくなってやめた。
netlifyは当然24時間営業なので、入口サイトを開けっ放しにしておくにはいいのでは？
ということでそうしてみた。
という経緯で、
した。
死んでる間のリンクは別に面倒見なくていいだろ。
サーバが起きたらまたリンクも生き返る。はず。
なんか自動起動のAutomationがうまく起動していなかった。
ロールの設定あたりが必要だったらしい。よくわからんけど、前に作ったときはそんなんなかったような気がするんだけどな……
とりあえず作り直したら動くようになった。
もう何年も、ああでもないこうでもないと方法を試行錯誤している。
手をかけたくないし、かと言ってR18虹をおける無料サバって存在が不安定。
有料でもいいかなとは思うのだけど。
自分のSSをGitlab管理しているのだけど、GitlabはSaaS版ではなくAzure上に構築している。SaaS版GitlabもエロNGのため。
Azureですでに金かかってるんで、退避所もGitlab-pagesに乗っけてエロOKサーバ代を圧縮したい。
でもGithubPagesはなんだかんだで管理が面倒くさい。特に証明書周り。
お名前.comでもお金かかっちゃってるしなあ。
PixivとかのSaaSにドカドカ登録するのが一番なんだろうけどなあ。